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CHAPTER  1 


INTRODUCTION 


The  Ada  inplementation  described  above  was  tested  according  to  the  Ada 
Validation  Procedures  [Pro90]  against  tt«  Ada  Standard  [Ada83]  tising  the 
current  Ada  Coo^iler  Validation  Capability  (ACVC).  This  Vali^tion  Sumnary 
Report  (VSR)  gives  an  account  of  the  testing  of  this  Ada  infileinentation. 

For  any  technical  terms  used  in  this  report,  the  reader  is  referred  to 
[Pro901.  A  detailed  description  of  the  ACVC  may  be  found  in  the  current 
ACVC  User's  Guide  (UG89]. 


1.1  USE  OF  THIS  VALIDATION  SUMMARY  REPC»T 

Consistent  vdth  the  national  laws  of  the  originating  country,  the  Ada 
Certification  Body  may  make  full  and  free  public  disclosure  of  this  report. 
In  the  united  States,  this  is  provided  in  accordance  with  the  "Freedom  of 
Information  Act"  (5  U.S.C.  #552).  The  results  of  this  validation  apply 
only  to  the  cciqputers,  operating  systems,  and  compiler  versions  identified 
in  this  report. 

The  organizations  represented  on  the  signature  page  of  this  report  do  not 
represent  or  warrant  that  all  statements  set  forth  in  this  report  are 
accurate  and  ccmplete,  or  that  the  subject  implementation  has  no 
nonconformities  to  the  Ada  Standard  other  than  those  presented.  Copies  of 
this  report  are  available  to  the  public  from  the  AVF  which  performed  this 
validation  or  from: 

National  Technical  Information  Service 
5285  Port  Royal  Road 
Springfield  VA  22161 

Questions  regarding  this  report  or  the  validation  test  resxilts  should  be 
directed  to  the  AVF  which  performed  this  validation  or  to; 

Ada  Validation  Organization 

Coiputer  and  Software  Engineering  Division 

Institute  for  Defense  Analyses 

1801  North  Beauregard  Street 

Alexandria  VA  22311-1772 
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1.2  REFERENCES 

[Ada83]  Reference  Nan\ial  for  the  Ada  Proqraaraing  Languaqe, 

ANSI/MIL-STD-i8i^,  February  19B5  and  ISO  8652-1987. 

[Pro90]  Ada  Compiler  Validation  Procedures,  Version  2.1,  Ada  Joint 
Program  Office,  August  1990. 

(UG89]  Ada  Compiler  Validation  Capability  User*s  Guide,  21  June  1989. 


1.3  ACVC  TEST  CIASSES 

Conpliance  of  Ada  inplementations  is  tested  by  means  of  the  ACVC.  The  ACVC 
contains  a  collection  of  test  programs  structured  into  six  test  classes:  A, 
B,  C,  D,  E,  and  L.  The  first  letter  of  a  test  name  identifies  the  class  to 
which  it  belongs.  Class  A,  C,  D,  and  E  tests  are  executable.  Class  B  and 
class  L  tests  are  expected  to  produce  errors  at  coBf>ile  time  and  link  time, 
respectively. 

The  executable  tests  are  written  in  a  self-checking  manner  and  produce  a 
PASSED,  FAILED,  or  NOT  APPLICABLE  message  indicating  the  resiilt  when  they 
are  executed.  Three  Ada  library  xjnits,  the  packages  REPORT  and  SPPRT13, 
and  the  procedure  CHECK^FILE  are  used  for  this  purpose.  The  package  REPCHtT 
also  provides  a  set  of  Identity  functions  used  to  defeat  some  caapiler 
optimizations  allowed  by  the  Ai^  Standard  that  would  circumvent  a  test 
objective.  The  package  SPPRT13  is  used  by  many  tests  for  Chapter  13  of  the 
Ada  Standard.  The  procedure  CHECK^FILE  is  used  to  check  the  contents  of 
text  files  written  by  scxne  of  the  Class  C  tests  for  Chapter  14  of  the  Ada 
Standard.  The  operation  of  REPORT  and  CHECK_FILE  is  checked  by  a  set  of 
executable  tests.  If  these  units  are  not  operating  correctly,  validation 
testing  is  discontinued. 

Class  B  tests  check  that  a  conpiler  detects  illegal  language  usage.  Class 
B  tests  are  not  executable.  Each  test  in  this  class  is  compiled  and  the 
resulting  ccmpilation  listing  is  examined  to  verify  that  all  violations  of 
the  Ada  Standard  are  detected.  Some  of  the  class  B  tests  contain  legal  Ada 
code  which  must  not  be  flagged  illegal  by  the  conpiler.  This  behavior  is 
also  verified. 

Class  L  tests  check  that  an  Ada  inplementation  correctly  detects  violation 
of  the  Ada  Standard  involving  multiple,  separately  conpiled  units.  Errors 
are  expected  at  link  time,  and  execution  is  attenpted. 

In  some  tests  of  the  ACVC,  certain  macro  strings  have  to  be  replaced  by 
implementation-specific  values  —  for  exanple,  the  largest  integer.  A  list 
of  the  values  used  for  this  inplementation  is  provided  in  i^pendix  A.  In 
addition  to  these  anticipated  test  modifications,  additional  changes  may  be 
required  to  remove  unforeseen  conflicts  between  the  tests  and 
inplementation-dependent  characteristics.  The  modifications  required  for 
this  inplementation  are  described  in  section  2.3. 
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For  each  Ada  inf>leinentation,  a  customized  test  suite  is  produced  by  the 
AVF.  This  customization  consists  of  making  the  modifications  described  in 
the  preceding  paragraph,  removing  withdravm  tests  (see  section  2.1),  and 
possibly  removing  some  inapplicable  tests  (see  section  2.2  and  (UG89]). 

In  order  to  pass  an  ACVC  an  Ada  implementation  must  process  each  test  of 
the  customized  test  suite  according  to  the  Ada  Standard. 


1.4  DEFINITION  OF  TERMS 

Ada  Compiler  The  software  and  any  needed  hardware  that  have  to  be  added 
to  a  given  host  and  target  conputer  system  to  allow 
treuisformation  of  Ada  programs  into  execut2d>le  form  and 
execution  thereof. 

Ada  Ccmpiler  The  means  for  testing  conpliance  of  Ada  implementations. 
Validation  consisting  of  the  test  suite,  the  support  programs,  the  ACVC 
Capatbility  user's  guide  and  the  tenplate  for  the  validation  summary 

(ACVC)  report. 

Ada  An  Ada  conpiler  with  its  host  conputer  system  and  its 

Implementation  target  cooputer  system. 

Ada  Joint  The  part  of  the  certification  body  which  provides  policy  and 
Program  guidtoce  for  the  Ada  certification  system. 

Office  (AJPO) 

Ada  The  part  of  the  certification  body  vdiich  carries  out  the 

Validation  procedures  required  to  est2d3li5h  the  compliance  of  an  Ada 
Facility  (AVF)  inplementation. 

Ada  The  part  of  the  certification  body  that  provides  technical 

Validation  guid^ce  for  operations  of  the  Ada  certification  system. 

Organization 
(AVO) 

Conpliance  of  The  ability  of  the  implementation  to  pass  an  ACVC  version, 
an  Ada 

Inplementation 

Computer  A  functional  unit,  consisting  of  one  or  more  conputers  and 

System  associated  software,  that  uses  common  storage  for  all  or 

part  of  a  program  and  also  for  all  or  part  of  the  data 
necessary  for  the  execution  of  the  program;  executes 
user-written  or  user-designated  progreuns;  performs 
user-designated  data  manipulation,  including  arithmetic 
operations  and  logic  operations;  and  that  can  execute 
programs  that  modify  themselves  during  execution.  A 
computer  system  may  be  a  stand-alone  vjnit  or  may  consist  of 
several  inter-connected  units. 


IHraODUCTION 


Conformity  Fulfillment  by  a  product,  process,  or  service  of  all 
requirements  specified. 

Customer  An  individual  or  corporate  entity  who  enters  into  an 

agreement  with  an  AVF  which  specifies  the  terms  and 
conditions  for  AVF  services  (of  any  kind)  to  be  performed. 

Declaration  of  A  formal  statement  from  a  customer  assuring  that  conformity 
Conformance  is  realized  or  attainable  on  the  Ada  implementation  for 
which  validation  status  is  realized. 

Host  Computer  A  computer  system  v^ere  Ada  source  programs  are  transformed 
System  into  executable  form. 

Inapplicable  A  test  that  contains  one  or  more  test  objectives  found  to  be 
test  irrelevant  for  the  given  Ada  implementation. 

ISO  International  Orgemization  for  Standardization. 

LBH  The  Ada  standard,  or  Language  Reference  Meuiual,  published  as 

ANSI/MIL-STD-1815A-1983  and  ISO  8652-1987.  Citations  frcxn 
the  LRM  take  the  form  "<section>.<subsection>:<paragraph>." 

Operating  Software  that  controls  the  execution  of  programs  and  that 
System  provides  services  such  as  resource  allocation,  scheduling, 

input/output  control,  and  data  management.  Usually, 
operating  systems  are  predominantly  software,  but  partial  or 
conplete  hardware  inplen^ntations  are  possible. 

Target  A  conputer  system  where  the  executable  form  of  Ada  programs 

Conputer  are  executed. 

System 

Validated  Ada  The  conpiler  of  a  validated  Ada  implementation. 

Compiler 

Validated  Ada  An  Ada  inplementation  that  has  been  validated  successfully 
Inplementation  either  by  AVF  testing  or  by  registration  lPro90). 

Validation  Hie  process  of  checking  the  conformity  of  an  Ada  conpiler  to 
the  Ada  programming  language  and  of  issuing  a  certificate 
for  this  implementation. 

Withdrawn  A  test  found  to  be  incorrect  and  not  used  in  conformity 

test  testing.  A  test  may  be  incorrect  because  it  has  an  invalid 

test  objective,  fails  to  meet  its  test  objective,  or 
contains  erroneous  or  illegal  use  of  the  Ada  programming 
Ictnguage. 
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IMPLEMEinATIGN  DEPElQDEiaCIES 


2.1  WITHDRAWN  TESTS 

The  following  tests  have  been  withdrawn  by  the  AVO.  The  rationale  for 
withdrawing  each  test  is  available  frm  either  the  AVO  or  the  AVF.  Ihe 
publication  date  for  this  list  of  withdrawn  tests  is  2  August  1991. 


E28005C 

B28006C 

C32203A 

C34006D 

C35508I 

C35508J 

C35508M 

C35508N 

C35702A 

C35702B 

B41308B 

C43004A 

C45114A 

C45346A 

C45612A 

C45612B 

C45612C 

C45651A 

C46022A 

B49008A 

B49008B 

A74006A 

C7430aA 

B83022B 

B83022H 

B83025B 

B83025D 

C83026A 

Be3026B 

C83041A 

B85001L 

C86001F 

C94021A 

C97116A 

C98003B 

BA2011A 

CB7001A 

CB7001B 

CB7004A 

CC1223A 

BC1226A 

CC1226B 

BC3009B 

BD1B02B 

BD1B06A 

AD1B08A 

BD2A02A 

CD2A21E 

CD2A23E 

CD2A32A 

CD2A41A 

CD2A41E 

CD2A87A 

CD2B15C 

BD3006A 

BD4008A 

CD4022A 

CD4022D 

CD4024B 

CD4024C 

CD4024D 

CD4031A 

CD4051D 

CD5111A 

CD7004C 

ED7005D 

CD7005E 

AD7006A 

CD7006E 

AD7201A 

AD7201E 

CD7204B 

AD7206A 

BD8002A 

BD8004C 

CD9005A 

CD9005B 

CDA201E 

CE2107I 

CE2117A 

CE2117B 

CE2119B 

CE2205B 

CE2405A 

CE3111C 

CE3116A 

CE3118A 

CE3411B 

CE3412B 

CE3607B 

CE3607C 

CE3607D 

CE3812A 

CE3814A 

CE3902B 

2.2  INAPPLICABLE  TESTS 

A  test  is  inapplicable  if  it  contains  test  objectives  which  are  irrelevant 
for  a  given  Ai^  inplenentation.  Reasons  for  a  test's  inapplicability  may 
be  supported  by  documents  issued  by  the  ISO  and  the  AJPO  known  as  Ada 
Ccamnentaries  and  commonly  referenced  in  the  format  Al-ddddd.  For  this 
implementation,  the  following  tests  were  determined  to  be  inapplicable  for 
the  reasons  indicated;  references  to  Ada  Commentaries  are  included  as 
appropriate. 


2-1 


ZMPLEHEMIATIGN  DEPENDENCIES 


itie  following  201  tests  have  floating-point  type  declarations 
requiring  more  digits  them  SYSTEM. MAX_DI GITS: 

C24U3L..Y  (14  tests)  C35705L..Y  (14  tests) 

C35706L..Y  (14  tests)  C35707L..Y  (14  tests) 

C35708L..Y  (14  tests)  C35802L..Z  (15  tests) 

C45241L..Y  (14  tests)  C45321L..Y  (14  tests) 

C45421L..Y  (14  tests)  C45521L..Z  (15  tests) 

C45524L..Z  (15  tests)  C45621L..Z  (15  tests) 

C45641L..Y  (14  tests)  C46012L..Z  (15  tests) 

C35713B,  C45423B,  B86001T,  and  C86006H  checit  for  the  predefined  type 

SHORT_FLOAT;  for  this  inplementation,  there  is  no  such  type. 

C35713D  and  B86001Z  check  for  a  predefined  floating-point  type  with  a 
name  other  than  FLOAT,  L0NG_FL0AT,  or  SHORT_FLCAT;  for  this 
implementation,  there  is  no  such  type. 

C45531M..P  and  C45532M..P  (8  tests)  check  fixed-point  operations  for 
types  that  require  a  SYSTEM. MAX_MANTISSA  of  47  or  greater;  for  this 
implementation,  MAX_MANTISSA  is  less  than  47. 

C45624A. .B  (2  tests)  check  that  the  proper  exception  is  raised  if 
MACHINE_OVERFLOWS  is  FALSE  for  floating  point  types  and  the  results  of 
various  floating-point  operations  lie  outside  the  range  of  the  Isase 
type;  for  this  implementation,  MACHlNEjDVERFLCWS  is  TRUE. 

D55A03E..H  (4  tests)  use  31  levels  of  loop  nesting;  this  level  of  loop 
nesting  exceeds  the  capacity  of  the  cranpiler. 

D64005G  uses  17  levels  of  recursive  procedure  calls  nesting;  this 
level  of  nesting  for  procedure  calls  exceeds  the  capacity  of  the 
compiler. 

B86001Y  uses  the  name  of  a  predefined  fixed-point  type  other  than  type 
DURATICM;  for  this  inplementation,  there  is  no  such  type. 

CA2009C  and  CA2009F  check  whether  a  generic  unit  can  be  instantiated 
before  its  body  (and  any  of  its  sulcunits)  is  compiled;  this 
implementation  creates  a  dependence  on  generic  units  as  allowed  by 
AI-00408  and  AI-00506  such  that  the  compilation  of  the  generic  unit 
bodies,  makes  the  instantiating  units  obsolete.  (See  section  2.3.) 

CD1009C  checks  vrtiether  a  length  clause  can  specify  a  non-defa\ilt  size 
for  a  floating-point  type;  this  inplementation  does  not  support  such 
sizes. 

a)2A84A,  CD2A84E,  CD2A84I..J  (2  tests),  and  CD2A840  use  length  clauses 
to  specify  non-default  sizes  for  access  types;  this  in^lementation 
does  not  support  such  sizes. 


2-2 


IMPLENENIATION  DEPENDE^IES 


AE2101C  and  EE2201D. .E  (2  tests)  use  instantiations  of  package 
SEQlIQn'lAL_IO  with  unconstrained  array  types  and  record  types  with 
discriminants  without  defaults;  these  instantiations  are  rejected  by 
this  compiler . 

AE2101H,  EE2401D,  and  EE2401G  use  instantiations  of  package  DIRECT_IO 
with  unconstrained  array  types  and  record  types  with  discriminants 
without  defaults;  these  instantiations  are  rejected  by  this  ccmpiler. 

The  following  260  tests  check  operations  on  sequential,  text,  and 
direct  access  files;  this  implementation  does  not  support  external 
files: 


CE2102A.  .C 

(3) 

C:e2102G.  .H 

(2) 

CE2102K 

CE2102N..y 

(12) 

CE2103C. .D 

(2) 

CE2104A. .D 

(4) 

CE2105A..B 

(2) 

CE2106A..B 

(2) 

CE2107A.  .H 

(8) 

CE2107L 

CE2108A. .H 

(8) 

CE2109A. .C 

(3) 

CE2110A.  .D 

(4) 

CE2111A. .1 

(9) 

CE2115A.  .B 

(2) 

CE2120A. .B 

(2) 

CE2201A.  .C 

(3) 

CE2201F. .N 

(9) 

CE2203A 

CE2204A. .D 

(4) 

CE2205A 

CE2206A 

CE2208B 

CE2401A. .C 

(3) 

CE2401E..F 

(2) 

CE2401H. .L 

(5) 

CE2403A 

C:E2404A.  .B 

(2) 

CE2405B 

CE2406A 

CE2407A. .B 

(2) 

CE2408A.  .B 

(2) 

CE2409A.  .B 

(2) 

CE2410A. .B 

(2) 

CE2411A 

CE3102A..C 

(3) 

CE3102F..H 

(3) 

CE3102J..K 

(2) 

CE3103A 

CE3104A. .C 

(3) 

CE3106A.  .B 

(2) 

CE3107B 

CE3108A. .B 

(2) 

CE3109A 

CE3110A 

CE3111A.  .B 

(2) 

CE3mD..E 

(2) 

CE3112A. .D 

(4) 

CE3114A.  .B 

(2) 

CE3115A 

CE3119A 

EE3203A 

EE3204A 

CE3207A 

CE3208A 

CE3301A 

EE3301B 

CE3302A 

CE3304A 

CE3305A 

CE3401A 

CE3402A 

EE3402B 

a;3402C.  .D 

(2) 

CE3403A.  .C 

(3) 

CE3403E..F 

(2) 

CE3404B..D 

(3) 

CE3405A 

EE3405B 

CE3405C. .D 

(2) 

CE3406A. .D 

(4) 

CE3407A.  .C 

(3) 

CE3408A. .C 

(3) 

CE3409A 

CE3409C..E 

(3) 

EE3409F 

CE3410A 

CE3410C..E 

(3) 

EE3410F 

CE3411A 

CE3411C 

CE3412A 

EE3412C 

CE3413A..C 

(3) 

CE3414A 

CE3602A. .D 

(4) 

CE3603A 

CE3604A.  .B 

(2) 

CE3605A..E 

(5) 

CE3606A..B 

(2) 

CE3704A. .F 

(6) 

CE3704M. .0 

(3) 

CE3705A..E 

(5) 

CE3706D 

CE3706F.  .G 

(2) 

CE3804A. .P 

(16) 

CE3805A..B 

(2) 

CE3806A.  .B 

(2) 

CE3806D. .E 

(2) 

CE3806G. .H 

(2) 

CE3904A.  .B 

(2) 

CE3905A.  .C 

(3) 

CE3905L 

CE3906A. .C 

(3) 

CE3906E..F 

(2) 

CE2103A,  CE2103B,  and  CE3107A  use  an  illegal  file  name  in  an  attempt 
to  create  a  file  and  expect  NAME_ERROR  to  be  raised;  this 
implementation  does  not  support  external  files  and  so  raises 
USE  ERROR.  ( See  section  2.3.) 


IHPLENENIATION  DEPENDENCIES 


2.3  TEST  MODIFICATIONS 

Modifications  (see  section  1.3)  were  required  for  10  tests. 

The  following  tests  were  split  into  two  or  more  tests  because  this 
implementation  did  not  report  the  violations  of  the  Ada  Standard  in  the  way 
expected  by  the  original  tests. 

B22003A  B83033B  B85013D 

CA2009C  and  CA2009F  were  graded  inapplicable  by  Evaluation  Modification  as 
directed  by  the  AVO.  These  tests  contain  instantiations  of  a  generic  unit 
prior  to  the  separate  compilation  of  that  unit's  body;  as  allowed  by 
AZ-257,  this  implementation  requires  that  the  bodies  of  a  generic  mit  be 
in  the  same  compilation  if  instantiations  of  that  unit  precede  the  bodies. 
The  implementation  issues  error  messages  at  link  time  that  the  main  program 
"has  imresolved  generic  instantiations"  and  the  tests  cannot  be  executed. 

BC3204C  and  BC3205D  were  graded  passed  by  Processing  Modification  as 
directed  by  the  AVO.  These  tests  check  that  instantiations  of  generic 
units  with  unconstrained  types  as  generic  actual  parameters  are  illegal  if 
the  generic  bodies  contain  uses  of  the  types  that  require  a  constraint. 
However,  the  generic  bodies  are  compiled  after  the  units  that  contain  the 
instantiations,  eund  this  implementation  creates  a  dependence  of  the 
instantiating  units  on  the  generic  units  as  allowed  by  AI-00408  and 
AI-00506  such  that  the  compilation  of  the  generic  bodies  makes  the 
instantiating  units  obsolete — no  errors  are  detected.  The  processing  of 
these  tests  was  modified  by  re-compiling  the  obsolete  units;  all  intended 
errors  were  then  detected  by  the  compiler. 

CE2103A,  CE2103B,  and  CE3107A  were  graded  inapplicable  by  Evaluation 

Modification  as  directed  by  the  AVO.  The  tests  abort  with  an  unhandled 
exception  v*ien  USE_ERROR  is  raised  on  the  attempt  to  create  an  external 
file.  This  is  acceptedile  behavior  because  this  implementation  does  not 
sipport  external  files  (cf.  AI-00332). 
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CHAPTER  3 


PROCESSING  INFORMATION 


3.1  TESTING  ENVIRONMENT 


The  Ada  inplementation  tested  in  this  validation  effort  is  described 
adequately  by  the  information  given  in  the  initial  pages  of  this  report. 

For  technical  and  sales  information  about  this  Ada  implementation,  contact: 

Mike  I^er 
Intermetrics  Inc. 

733  Concord  Avenue 
Cambridge  MA  02138-1002 
(617)  661-1840 


Testing  of  this  Ada  implementation  was  conducted  at  the  customer's  site  by 
a  vali^tion  team  from  the  AVF. 


3.2  SUMMARY  OF  TEST  RESULTS 

An  Ada  Implementation  passes  a  given  ACVC  version  if  it  processes  each  test 
of  the  customized  test  suite  in  accordance  with  the  Ada  Programming 
Language  Standard,  vAiether  the  test  is  applicedsle  or  inapplicable; 
otherwise,  the  Ada  Implementation  fails  ti:e  ACVC  [Pro90]. 

For  all  processed  tests  ( inapplicable  and  applicable ) ,  a  resiilt  was 
obtained  that  conforms  to  the  Ada  Programming  Language  Standard. 

The  list  of  items  below  gives  the  num^r  of  ACVC  tests  in  various 
categories.  All  tests  were  processed,  except  those  that  were  withdrawn 
because  of  test  errors  (item  b;  see  section  2.1),  those  that  require  a 
floating-point  precision  that  exceeds  the  implementation's  maximum 
precision  (item  e;  see  section  2.2),  and  those  that  depend  on  the  support 
of  a  file  system  —  if  none  is  supported  (item  d).  All  tests  passed, 
except  those  that  are  listed  in  sections  2.1  and  2.2  (counted  in  items  b 
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PROCESSING  INFORMATION 


and  £,  below) . 


a)  Total  Number  of  Applicable  Tests  3575 

b)  Total  Number  of  Withdrawn  Tests  95 

c)  Processed  Inapplicable  Tests  39 

d)  Non-Processed  I/O  Tests  260 

e)  Non-Processed  Floating-Point 

Precision  Tests  201 

f)  Total  Number  of  Inapplicable  Tests  500  (c+d+e) 


g)  Total  Number  of  Tests  for  ACVC  1.11  4170  (a+b+f) 


3.3  TEST  EXECUTIOl 

A  TK-50  cartridge  tape  containing  the  customized  test  suite  (see  section 
1.3)  was  taken  on-site  by  the  validation  team  for  processing.  The  contents 
of  the  TK-50  cartridge  tape  were  loaded  directly  onto  the  host  computer. 

After  the  test  files  were  loaded  onto  the  host  computer,  the  full  set  of 
tests  was  processed  by  the  Ada  inplementation. 

The  tests  were  conpiled  and  linked  on  the  ccmputer  system,  as  appropriate, 
and  run.  The  results  were  captured  on  the  ccnputer  system. 

Testing  was  performed  using  command  scripts  provided  by  the  custcmier  and 
reviewed  by  the  validation  team.  See  ^)pendix  B  for  a  complete  listing  of 
the  processing  options  for  this  inplementation.  It  also  indicates  the 
default  options.  The  options  invoked  explicitly  for  validation  testing 
during  this  test  were: 

Option/Switch  Effect 

Compiler  Options 

/LIST  Generate  a  compilation  listing  with  default 

listing  format.  Used  for  E  tests. 

-Ic  Generate  a  ccxipilation  listing  with  continuous 

listing  format.  Used  for  all  other  tests. 

Program  Builder  options 

/PASS-llink_options  Pass  options  to  the  linker  locator. 

Linker/Locator  options 
/LL-adabase : [ lib ] t rwmpk . Ibl 

Name  of  library  index  file  to  be  used  for 
vinresolved  references. 

/C-adabase : [ lib ] trwmpk . 11c 

Name  of  file  containing  locator  commands. 
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/SE  Eliminate  iinreferenced  segments. 

/US»( "atatOOl" , "rtl_stack" , "addres6_space_descriptor" ) 

Mark  indicated  symbols  as  referenced  before 
determining  unreferenced  segments. 


St  output,  compiler  and  linker  listings,  euid  job  logs  were  captured  on 
-50  cartridge  tape  and  archived  at  the  AVF.  Die  listings  examined 
-site  by  the  validation  team  were  also  archived. 
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APPENDIX  A 
MACRO  PARAMETERS 


Ihis  appendix  contains  the  macro  parameters  used  for  customizing  the 
The  meaning  and  purpose  of  these  parameters  are  explained  in  (UG89]. 
parameter  values  are  presented  in  tvfo  tables.  Ihe  first  table  lists 
values  that  are  defined  in  terms  of  the  maximum  input-line  length,  vAi 
the  value  for  $MAX_IN_LEN — also  listed  here.  These  values  are  exprea 
here  as  Ada  string  aggregates,  where  "V  represents  the  maximum  input-line 
leng^. 


Macro  Parameter 


Macro  Value 


$MAX_IN_LEN 

$BIG_ID1 

$BIG_ID2 

$BIG_ID3 

$BIG_ID4 


200  —  Value  of  V 

(1..V-1  ->  'A',  V  ->  '1') 

(1..V-1  ->  'A',  V  ->  '2') 

(1..V/2  ->  'A')  &  '3'  C. 
(1..V-1-V/2  ->  'A') 

(1..V/2  ->  'AM  *  '4'  & 
(1..V-1-V/2  ->  'A') 


$BIG_INT_LIT 

$BIG_REAL_HT 

$BIG_STRING1 

$BIG_STRING2 

$BLANKS 


{1..V-3  ->  '0')  &  "298" 

(1..V-5  ->  '0')  &  "690.0" 

&  (1..V/2  ->  'A' )  & 

&  (1..V-1-V/2  ->  'A')  &  '1'  & 
(1..V-20 


$MAX_LEN_INT_BASED_LITERAL 

"2:"  &  (1..V-5  ->  '0')  &  "11:" 

$MAX_LEN_REAL_BASED_LITERAL 

"16;"  &  (1..V-7  ->  '0')  &  "F.E;" 


MACRO  PARAMETERS 


$MAX_STRING_LITERAL  &  (1..V-2  ->  'A')  & 


The  following  table  lists  all  of  the  other  macro  parameters  and  their 
respective  values. 

Macro  Parameter  Macro  Valiie 


$ACC_SIZE 

$ALIGMMENT 

$COUNT_LAST 

$MTAULT_MEM_SI2E 

$DEFAULT_ST0R_UN1T 

$DEFAULT_SYS_NAME 

$DELTA_DOC 

$EJrnRY_ADDRESS 

$ENTRY_ADDRESS1 

$EWTRY_ADDRESS2 

$FIELD_LAST 

$FILE_TERM1NAT0R 

$F1XED_NAME 

$FLQAT_NAME 

$FORM_STRING 


32 

4 

2_147_483_647 

2_147_483_648 

8 

TRW_RH32 

2.0**(-31) 

16#1# 

16«2« 

16#3# 

2_147_483_647 

P  9 

NO_SUCH_FIXED_TYPE 

NO_SUCH_FLQAT_TyPE 

ff  ft 


$P0RM_£Tl;llvG2  "att«WTJElESTRICT_FILE_CAPACITY" 

$(2^TER_THAN_DURATIGN 

90_000.0 

$GREATER_THAN_DURATION  BASE  LAST 

T0_00^_000.0 

$GREATER_THAN_FLOAT_BASE  LAST 

3.I1E+38 

$GREATER_THAN_FLOAT_SAFE  LAi«3E 

1.0238 
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$GREATBR_THAN  SHCStT  FLOAT  SAFE_LARfX 

1.0138 

$HlCa_PRIORITY  31 

$ZIXEGAL_E}CIERNAL_FILE_NAME1 

NO_FILES_AT_ALL_l 

$ILLEGAL_E}CrERNAL_FZLE_NAME2 

NO_FILES_AT_ALL_2 

$INAPPROPRIATE_LINE  LQX3TH 

-1 

$INAPPR0PR1ATE_PAGE_LE1«3TH 

-1 


$ZNCLUC«_PRAGHA1 
$IMCLUDE_PRAGHA2 
$INTEGER_FIRST 
$INTEGER  LAST 


PRAGMA  INCLUDE  ( "A28006D1  .ADT" } 
PRAGMA  INCLUDE  ( "B28006F1 . ADT* ) 
-2147483648 
2147483647 


$INIEGER_LAST_PLUS_1  2147483648 

$INTERFACE_LANGUAGE  ASSEMBLY 

SLESS_THAN_DORATION  -90_000.0 

$LESS_THAN_DURATZQN  BASE  FIRST 

-1^000000.0 


$LINE_TERMINATOR 
$LC3W  PRIORITY 


ASCII. LF 
1 


$MACHINE_C(X)E_STATEME2(rr 

Fonnat  K  RMT  JR, true, R3); 


$MACHINEJCX»E_TYPE 

$MANTISSA_DOC 

$MAX_DIGITS 

$MAX_INT 

$MAX_INT_PLUS_1 

$MIN_INT 

$NAHE 


Fonnat_R_Lit 

31 

15 

2147483647 

2_147_483_648 

-2147483648 

BYTE_INTECTR 
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$NAME_LIST 

HNW_RH32 , raw_RH32 

$NAME_SPBC1FICATI0N1 

MO_FILES_l 

$NAME_SPEC1FICATI0N2 

NO_FILES_2 

$IiAHE_SPECIFICATIGN3 

N0_FILES_3 

$NBG_aASE2>_INT 

16«F000000E« 

$NEW_MEM_SIZE 

2147483648 

$NEW_ST0R_UN1T 

8 

$NEW_SYS_NAME 

IOgW_RH32 

$PAGE_TERHINATOR 

ASCII. FF 

$RECORD_DEFINITION 

RECORD  MNEMONIC: MNEMONIC  FIn'UH 
REG:REGISTER_ENUM;  END  RECORD 

$RECORO_NAME 

PORMAT_R 

$TASK_SZZE 

32 

$TASK_STOFAGE_SIZE 

2048 

$T1CK 

2.0**(-14) 

$VARZABLE_AIE«ESS 

16#3FFD0# 

$VAR1ABLE_ADDRESS1 

16#3FFF4# 

$VAR1ABLE_AZX)RESS2 

16#3FFF8# 

$YOUR  PRAGMA 

APART 
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APPENDIX  B 

CQHPIIATIQN  SYSTEM  OPTIGNS 


The  caqpiler  options  of  this  Ada  implementation,  as  described  in  this 
Appendix,  are  provided  by  the  customer.  Unless  specifically  noted 
otherwise,  references  in  this  appendix  are  to  ccopiler  documentation  and 
not  to  this  report. 
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Inputs 


Invocation 


adatxw 


Options 

/dabug  Generate  debugging  output.  The  /dabug  option  causes  the  compiler  to  generate  the  ap¬ 
propriate  code  and  data  for  operation  with  the  RISCAE  Debugger. 

/arror^log  Generate  error  log  file.  The/arxor_log  option  causes  the  compiler  to 

generate  a  log  file  containing  all  the  error  messages  and  warning  messages  produced  during  com¬ 
pilation.  The  error  log  file  has  the  same  name  as  the  source  file,  with  the  extension  .arr.  For 
example,  the  error  log  file  for  alapla  .ada  is  alapla  .arr.  The  error  log  file  is  placed  in  the 
cunent  working  directory.  In  the  absence  of  the /liat  option,  the  error  log  information  is  sent  to 
the  standard  output  stream. 

/xtuat_ehaeka_8uopraaa  Suppress  numeric  checking.  The  /Bum_ehacks_supprasa  option 
suppresses  two  kinds  of  numeric  checks  for  the  entire  compilation: 

1.  division.check 

2.  overflow.check 

These  checks  are  described  in  section  11.7  of  theLRM.  Using /nua.ehaefca^Bupprasa  re¬ 
duces  the  size  of  the  code.  Note  that  there  is  a  related  adatnr  option.  /all_ehaeka_aup- 
prass  to  suppress  all  checks  for  a  compilation. 

/all_cbaelca_suppraas  Suppress  all  checks.  The  /all_chaeks_8uppraaa  option  suppresses 
all  automatic  checking,  including  numeric  checking.  This  option  is  equivalent  to  using  pragma 
aupprasa  on  all  checks.  This  option  reduces  the  size  of  the  code,  and  is  good  for  producing  “pro¬ 
duction  quality”  code  or  for  benchmarking  tte  compiler.  Note  that  there  is  a  related  adatzw  op¬ 
tion,  /xnim_elxaeka_auppraas  to  suppress  only  certain  kinds  of  numeric  checks. 

/warnlag.suppraaa 

Suppress  warning  messages.  With  this  option,  the  compiler  does  not  print  warning  messages  about 
ignored  pragmas,  exceptions  that  are  ceitain  to  be  raised  at  run-time,  or  other  potential  problems  that 
the  compiler  is  otherwise  forbidden  to  deem  as  errors  by  the  LRM. 

/no_dnl«t« 

Keep  internal  form  file.  This  option  is  for  use  by  compiler  maintainers.  Without  this  option,  the 
compiler  deletes  internal  form  files  following  code  generation. 

/lint 

Generate  listing  file.  The /list  option  causes  the  compiler  to  create  a  listing.  The  formats  of  and 
options  for  listings  are  discussed  in  section  3.2. 1.7.  The  default  listing  file  generated  has  the  same 
name  as  the  source  file,  with  the  extension  .  1st.  For  example,  the  default  listing  file  produced  for 
siaq^ls .  sds  has  the  name  siavls .  1st.  The  listing  file  is  placed  in  the  current  working  direc¬ 
tory.  In  order  to  generate  a  listing  in  the  continuous  listing  format,  use  the  -le  switch  rather  than  the 


/list  option.  Note;  /list  also  causes  an  error  log  file  to  be  produced,  as  with  the/«r- 
ror_log  option. 

/library 

Default:  ada.lib 

Use  alternate  library.  The  /library  option  specifies  an  alternative  name  for  the  program  Ubrary. 


COHPILATIGM  SYSTEM  OPTIGNS 


LINKER  OPTIONS 

The  linker  optic»is  of  this  Ada  isplementation,  as  described  in  this 
Appendix,  are  provided  by  the  custcxaer.  Unless  specifically  noted 
otherwise,  references  in  this  appendix  are  to  linker  documentation  and  not 
to  this  report. 


Inputs 


Invocation 


BMIF  taptiom  . . .  ]  ImoB-pneedure-moaui 


Options 


/  compiler=compiler_name 

Default:  acla .  lib 

Use  alternate  compiler.  The  /  compiler  option  specifies  the  complete  (non 
relative)  directory  path  to  the  RISCAEAda  compiler.  This  option  overrides 
the  compiler  program  name  stored  in  the  program  library.  The  /  compiler 
option  is  intended  for  use  by  system  maintainers. 


/ ma in_suppr e  s  s 

Suppress  main  program  generation  step.  The  /main.suppress  option  sup¬ 
presses  the  creation  and  additional  code  generation  steps  for  the  temporary 
main  program  file.  The  /main^suppress  option  can  be  used  when  a  sim¬ 
ple  change  has  been  made  to  the  body  of  a  compilation  unit  If  unit  elabora¬ 
tion  order  is  changed,  or  if  the  specification  of  a  unit  is  changed,  or  if  new 
units  are  added,  then  this  option  should  not  be  used.  The  /main.sup- 
press  option  saves  a  few  seconds,  but  places  an  additional  bookkeeping 
burden  on  you.  The  option  should  be  avoided  under  most  circumstances. 
Note  that  invoking  bamp  with  the  /  load_suppress  option  followed  by 
another  invocation  of  bamp  with  the  /inain_suppress  option  has  the 
same  effect  as  an  invocation  of  bamp  with  neither  option  (/  load^sup- 
press  and  /main_suppress  neutralize  each  other). 

/  lihzaTY=library-name 

Default:  ada .  lib 

Use  alternate  library.  The  /  library  option  specifies  the  name  of  the  pro¬ 
gram  library  to  be  consulted  by  the  banp  program.  This  option  overrides  the 
default  library  name. 


/ load_suppress 

No  link.  The  option  suppresses  actual  object  file  linkage,  but  creates  and  per¬ 
forms  code  generation  on  the  main  program  file.  Note  that  invoking  bamp 
with  the  option  followed  by  another  invocation  of  baitp  with  the  / 
main_suppress  option  has  the  same  effect  as  an  invocation  of  banp  with 
neither  option.  That  is,  and  /main.suppress  neutralite  each  other. 


RISCAE  Software 


Users  Manual 


/  di sp 1 ay_c  ommands 

No  operations.  The  /  displ ay _c ommands  option  causes  the  bamp  com¬ 
mand  to  do  a  “dry  run”;  it  prints  out  the  actions  it  takes  to  generate  the  execut¬ 
able  program,  but  does  not  actually  pertbrm  those  actions.  The  same  kind  of 
information  is  printed  by  the  /print_operations  option. 

/  ou.fput=output-file-name 

Use  alternate  executable  file  output  name.  The  /output  option  specifies 
the  name  of  the  executable  program  file  written  by  the  bamp  command.  This 
option  overrides  the  default  output  file  name  which  is  the  main  procedure 
name  concatenated  to  8  characters  with  file  extension  .  ab. 


/pass =llink-options 

Pass  options  to  the  Linking  Locator.  The /pass  option  specifies  the  Linnking 
Locator  options  which  are  passed  directly  to  the  Linking  Locator. 

/print_operations 

Print  operations.  The  /print.operations  option  causes  the  bamp  command  to 
print  out  the  actions  it  takes  to  generate  the  executable  program  as  the  actions 
are  performed. 

/verbose  Link  verbosely.  The  /verbose  option  causes  the  bamp  command  to  print 

out  information  about  what  actions  it  takes  in  building  the  main  program  such 
as: 

•  The  name  of  the  program  library  consulted. 

•  The  library  search  order  (listed  as  “saves”  of  the  library  units  used  by 
the  program). 

•  The  name  of  the  main  program  file  created  (as  opposed  to  the  main 
procedure  name). 

•  The  elaboration  order. 

•  The  name  of  the  executable  load  module  created. 


RISCAE  Software 


Users  Manual 


Inputs 


Invocation 

UOHC  iPROGLtau  IM  noil  t  ...]  lopt^ns  ] 


Linker  Options 

/LIB=(/ii>[,/i62....  Name  library  index  files  to  be  searched  for  unresolved  externals.  If  the  index 

])  file  indicates  that  a  given  external  can  be  resolved  by  reading  a  particular 

module,  that  module  is  included  in  the  link.  The  Librarian  section  explains 
how  library  files  are  built  and  managed.  If  a  module  name  in  the  library  index 
file  is  not  a  full  pathname,  11  ink  searches  for  the  module  in  the  directory 
containing  the  index  file. 

/LL^iifh[,ifh2,...])  Read  library  index  to  be  searched  from  file  ifii.  Index  file  ipi  lists  all  libraries 
that  would  be  specified  on  the  command  line  if  the  /LIB  switch  were  used. 

Note:  The  linker  portion  of  the  linking  locator  may  not  always  search 
the  libraries  in  the  order  given.  See  the  Library  Searches  subsection 
for  more  details. 

/SE  Eliminate  unreferenced  segments  in  object  modules  during  linking.  This  op¬ 

tion  has  no  effect  unless  the  /US  option  is  used. 

/US=(”sym”  ”sym  Mark  the  specified  symbols  as  referenced  before  determining  unreferenced 

2”...)  segments.  The  symbols  may  be  global  symbols  or  segment  names.  This  op¬ 

tion  has  no  effect  unless  the  /SE  option  is  used. 

Locator  Options 

Locate  processing  is  done  by  default.  If  the  /LO  switch  is  present,  locate  pro¬ 
cessing  is  not  performed.  When  locate  processing  is  performed,  output  is 
written  to  PROG.AB  unless  the  /O  switch  is  specified. 

/C=cfti  Read  locator  commands  from  file  cfit. 

/  LO  Suppress  locate  processing  (link  only).  If  no  ROM  processing  option  is  speci¬ 

fied.  write  output  to  PROG.LN. 

/  P=n  Pad  the  size  of  all  segments  by  n  bytes. 

/P=n%  Pad  the  size  of  all  segments  to  n  percent  of  their  original  size  (n  must  be  > 

1(X)). 
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ROM  Processing  Options 

ROM  processing  is  performed  if  and  only  if  some  ROM  processing  option 
is  present.  If  locate  processing  is  also  performed,  output  is  written  to 
PROG .  AB.  If  only  ROM  processing  is  performed,  the  output  is  written  to 
PROG. RMP  by  default.. 

/B=segname  Specify  the  name  of  the  segment  to  be  created.  The  default  name  is  rom- 

pOutSeg. 

/RC=classI[,class2....] 

Specifies  that  all  segments  of  the  named  class(es)  will  be  processed. 

/RS=segl[jeg2,...] 

Specifies  that  the  named  segment(s)  will  be  processed. 


Symbol  Options 

/K[=“sym,sym2,...”] 

Keep  only  the  named  global  symbols  in  the  ouput  module:  suppress  all  oth¬ 
ers.  If  no  symbols  are  named,  suppress  all  global  symbols. 

/SP(=‘'sym,sym2,...”] 

Suppress  the  named  global  symbols  in  the  output  module;  keep  all  others. 

Global  symbols  are  generated  by  the  compiler  and  assembler  for  global  vari¬ 
ables  and  procedures.  The  compiler’s  rules  for  forming  global  symbol  names 
are  described  in  the  RISCAE  Software  Programmer  s  Manual.  Note  that  the 
names  specified  in  /SP  and  /K  must  be  formed  via  these  conventions. 

Generally  all  global  symbols  must  be  retained  in  the  output  module  to  permit 
any  further  references  to  be  resolved  during  later  links.  Specific  global  sym¬ 
bols  may  be  suppressed  to  mask  name  conflicts.  The  switches  which  apply 
to  global  symbols  are  mutually  exclusive. 

If  no  debugging  is  intended  and  the  link  is  complete,  all  symbols  may  be 
stripped.  Stripping  symbols  reduces  the  amount  of  disk  space  required  to 
hold  the  output  module  and  speeds  up  the  execution  of  llink  and  the  formatter. 
It  does  not  affect  the  size  of  the  user  program  or  the  download  hex  file  gener¬ 
ated  by  the  formatter. 

Miscellaneous  Options 

/  0  (Zero)  Displays  the  version  number  of  the  executable  (for  technical  support 

purposes). 

/  l[=ifti\  This  switch  specifies  that  the  names  of  input  object  modules  are  to  be  taken 

from  the  file  ifn.  The  input  module  names  should  be  listed  in  the  file,  one  per 
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line.  The  name  of  the  first  module  listed  will  be  used  as  a  default  for 
constructing  the  name  of  the  linked  output  file.  If  ifn  is  omitted,  the  names  of 
the  files  are  read  from  the  terminal. 


/  O(=o/h)  This  switch  specifies  the  name  of  the  output  file.  If  the  switch  is  omitted,  out¬ 

put  will  be  written  to  PROG.LN  or  prog.  RMP,  depending  on  the  switches  spe¬ 
cified. 

Verbose  mode.  Reports  the  following  linking  actions  as  performed; 

•  -  The  names  of  the  object  modules  being  read 

•  -  The  names  of  the  library  index  files  being  searched. 

•  -  The  name  of  the  output  module. 

/w  This  switch  inhibits  warning  messages.  If  11  ink  is  not  performing  the  lo¬ 

cate  function,  the  “unresolved  externals”  warning  is  the  only  warning  mes¬ 
sage  that  11  ink  can  emit.  This  can  safely  be  suppressed  if  unresolved  exter¬ 
nal  references  are  expected.  Other  warning  messages  represent  error 
conditions  and  should  not  in  general  be  ignored  or  suppressed. 
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APPENDIX  C 

APPENDIX  P  OF  THE  Ada  STANDARD 


The  only  allowed  inplenentation  dependencies  correspond  to 
implementation-dependent  pragmas,  to  certain  machine-dependent  conventioins 
as  mentioned  in  Chapter  13  of  the  Ada  Standard,  and  to  certain  allowed 
restrictions  on  representation  clauses.  The  inqplementation-dependent 
characteristics  of  this  Ada  implementation,  as  described  in  this  Appendix, 
are  provided  by  the  custCHner.  Unless  specifically  noted  otherwise, 
references  in  this  Appendix  are  to  compiler  documentation  and  not  to  this 
report.  Implementation-specific  portions  of  the  package  STANDARD,  vdiich 
are  not  a  part  of  ^^^ndix  F,  are: 


package  STANDARD  is 


type  INTEGER  is  range  -2147483648  ..  2147483647; 
type  LONG_INTEGER  is  range  -2147483648  ..  2147483647; 
type  SHORT_INTEGER  is  range  -32768  ..  32767; 
type  BYTE_INTEGER  is  reuige  -128  ..  127; 

type  FLOAT  is  digits  6  range  -3.40282E-I-38  ..  3.40282e-I'38; 

type  L0NG_FLCIAT  is  digits  15  range  -1.79769E+308  ..  1.79769E+308; 

type  DURATION  is  delta  2**-14  range  -86400.0  ..  86400.0; 


end  STANDARD; 


Appendix  F 

This  section  constitutes  Appendix  F  of  the  Ada  LRM  for  this  implementation.  Appendix  F  from  the  LRM 
states: 

The  Ada  language  allows  for  certain  machine-dependencies  in  a  controlled  manner.  No  machine- 
dependent  syntax  or  semantic  extensions  or  restrictions  are  allowed.  The  only  allowed  implementa¬ 
tion-dependencies  correspond  to  implementation-dependent  pragmas  and  attributes,  certain  ma¬ 
chine-dependent  conventions  as  mentioned  in  Chapter  13.  and  certain  allowed  restrictions  on 
representation  clauses. 

The  reference  manual  of  each  Ada  implementation  must  include  an  appendix  (called  Appendix  F) 
that  describes  all  implementation-dependent  characteristics.  The  Appendix  F  for  a  given  imple¬ 
mentation  must  list  in  particular: 

1.  The  form,  allowed  places,  and  effect  of  every  implementation-dependent  pragma. 

2.  The  name  and  the  type  of  every  implementation-dependent  attribute. 

3.  The  specification  of  the  package  SYSTEM. 

4.  The  list  of  all  restrictions  on  representation  clauses. 

5.  The  conventions  used  for  any  implementation-generated  name  denoting  implementation- 
dependent  components. 

6.  The  interpretation  of  expressions  that  appear  in  address  clauses,  including  those  for  inter¬ 
rupts. 

7.  Any  restriction  on  unchecked  conversions. 

8.  Any  implementation-dependent  characteristics  of  the  input-output  packages 
In  addition,  the  present  section  will  describe  the  following  topics: 

9.  Any  implementation-dependant  characteristics  of  tasking. 

10.  Other  implementation  dependencies. 

F.l:  Pragmas 

F.l.l:  Predefined  Language  Pragmas 

This  section  describes  the  form,  allowed  places,  and  implementation-dependent  effect  of  every  predefined 
language  pragma. 

F.1.1.1:  Pragmas  ELABORATE,  LIST,  OPTIMIZE,  PAGE,  AND  PRIORITY 

Pragmas  ELABORATE,  LIST,  OPTIMIZE,  PAGE,  and  PRIORITY  are  supported  exactly  in  the  form,  i.,  the 
allowed  places,  and  with  the  effect  as  described  in  the  LRM. 

F.1.1.2:  Pragma  SUPPRESS 

Form:  pragma  SUPPRESS  ( identifier  (.[ON  =>|  name\y, 

where  the  identifier  and  name,  if  present,  are  as  specified  in  LRM  B(  14).  Suppression  of  the  follow¬ 
ing  run-time  checks  are  supponed: 

ACCESS.CHECK 

DISCRIMINANT.CHECK 

INDEX.CHECK 


LENGTH.CHECK 

RANGE.CHECK 

DIVISION.CHECK 

OVERFLOW_CHECK 

ELABORATION.CHECK 

STORAGE.CHECK 

Allowed  Places:  as  specified  in  LRM  B(  14) .  SUPPRESS. 

Pennits  the  compiler  not  to  emit  code  in  the  unit  being  compiled  to  perform  various  checking  opera¬ 
tions  during  program  execution.  The  supported  checks  have  the  effect  of  suppressing  the  specified 
check  as  described  in  the  LRM  except  as  follows. 

•  The  suppression  of  DISCRIMINANT_CHECK  has  no  effect  if  the  pragma  is  not 
in  the  same  declarative  part  as  the  type  to  which  it  applies. 

•  The  suppression  of  ELABORATION.CHECK  has  no  effect  on  a  task  body. 

•  The  suppression  of  STORAGE_ERROR  does  not  suppress  the  check  that  an  al¬ 
locator  does  not  require  more  space  than  is  available. 

F.1.1.3:  Pragma  INLINE 

Form:  Pragma  INLINE  (.subprogram_namejcommaJist) 

Allowed  Places:  As  specified  in  LRM  B(4) :  INLINE 

Effect:  If  the  subprogram  body  has  already  been  compiled,  or  is  in  the  same  compilation  unit  as  the  call,  and 
if  the  subprogram  does  not  contain  nested  subprograms,  the  code  is  expanded  in-line  at  every  call 
site  and  is  subject  to  all  optimizations.  If  the  subprogram  to  be  inlined  is  recursive,  only  the  first  call 
is  inlined  and  the  recursive  call  is  a  normal  call. 

Exception  handlers  for  the  INLINE  subprogram  are  handled  as  for  block  statements. 

Use:  This  pragma  is  used  cither  when  it  is  believed  that  the  time  required  for  a  call  to  the  specified  routine 
will  in  general  be  excessive  (this  for  frequently  called  subprograms)  or  when  the  average  expected 
size  of  expanded  code  is  thought  to  be  comparable  to  that  of  a  call. 

F.1.1,4:  Pragma  INTERFACE 

Form:  Pragma  INTERFACE  {language _name,  subprogram_name\ ,  "linkjiame  ”1) 

where  the  language _n£une  must  be  assembly,  builtin,  or  internal,  and  the  subprogruiH_naine  is  as 
specified  in  the  LRM  B(S).  The  optional  link_naine  parameter  is  a  string  literal  specifying  the  entry 
point  label  of  the  non— Ada  subprogram  named  in  the  second  parameter.  If  link_natne  is  omitted, 
then  Unkjuune  defaults  to  the  value  of  subprogram  _name. 

Allowed  Hace:  As  specified  in  LRM  B(5) :  INTERFACE 

Effect.  Specifies  that  a  subprogram  will  be  provided  outside  the  Ada  program  library  and  will  be  callable 
with  a  specified  calling  interface.  Neither  an  Ada  body  nor  an  Ada  body_stub  may  be  provided  for 
a  subprogram  for  which  INTERFACE  has  been  specified.  Unkjume  is  used  as  the  entry  point  label 
of  the  subprogram.  The  language  jieme  builtin  and  internal  are  reserved  for  use  by  RISC  AE  com¬ 
piler  maintainers  in  run  time  support  packages. 

Use;  Use  with  a  subprogram  being  provided  via  another  program  language  and  for  which  no  body  will 
be  given  in  any  Ada  program. 


The  calling  conventions  for  an  Ada  program  calling  a  pragma  INTERFACE  (assembly)  subprogram 
are  according  to  the  RISCAE  Run  Time  Model  described  in  Appendix  C  of  the  RISCAE  Software 
Programmer’s  Manual. 

F.1.1.5:  Pragma  PACK 

Form .  Pragma  PAC K  ( type_simple_name) 

Allowed  Places;  As  specified  in  LRM  13.1  (12) 

Effect:  The  effect  of  pragma  PACK  is  to  minimize  storage  consumption  by  discrete  component  types  whose 
ranges  permit  packing.  Refer  to  the  RISCAE  Software  Programmer’s  Manual  for  more  information 
about  the  effect  of  pragma  PACK. 

Use:  Pragma  PACK  is  used  to  reduce  storage  size.  Size  reduction  usually  implies  an  increased  cost  of 
accessing  components.  The  decrease  in  storage  size  may  be  offset  by  increase  in  size  of  accessing 
code  and  by  slowing  of  accessing  operations. 

F.1.1.6:  Pragmas  SYSTEM,  NAME,  STORAGE  .UNIT,  MEMORY.SIZE,  CONTROLLED 
These  pragmas  are  not  supponed  and  are  ignored 

F.1.1.7:  Pragma  SHARED 

Form:  pragma  SHARED  (varicU>le ^simple _name) 

where  variable  jimpUjuune  is  of  any  scalar  type  except  longjloat. 

Allowed  Places:  As  specified  in  LRM  B(2) :  SHARED 

Effect  Direct  reading  and  direct  updating  of  the  specified  variable  must  be  implemented  as  an  indivisible 
operation.  In  addition,  the  implementation  must  ensure  that  each  reference  of  the  variable  is  made 
directly  ffom/to  memory  (i.e.  not  from  a  temporary  copy  of  t'  variable). 

Use:  This  is  used  to  cause  every  read  or  update  of  a  variable  to  be  a  ‘‘synchronization”  point  for  that  vari¬ 

able. 

F.1.2:  RISCAE-Defined  Pragmas 

F.L2.1:  F.1.2.2:  Pragma  APART 

Form:  pragma  APART  {variable_name[,  segname]) 

where  variable  jume  must  refer  to  a  static  objea.  (i.e.  a  variable  declared  in  a  library  unit  package 
specification  or  body,  or  in  a  package  specification  or  body  contained  in  a  library  unit  package)  and 
segname,  if  provided,  must  be  a  string  lita-al  which  specifies  the  name  of  the  segment  containing 
the  object. 

Allowed  Places:  Pragma  APART  is  allowed  in  the  declarative  region  of  a  library  unit  package  specification 
or  body,  or  in  a  package  specification  or  body  contained  in  a  library  unit  package.  The  declaration 
of  the  variable  must  be  in  the  same  declarative  region  as  the  pragma  and  must  proceed  the  occurrence 
of  the  pragma. 

Effect:  The  object  will  be  placed  in  a  segment  that  is  not  included  in  group  “dau”  and  consequently,  is  ad¬ 
dressed  directly  using  an  APART  dau  base  register  rather  than  the  global  base  register  (GBR).  If 
segname  is  provided,  it  is  used  as  the  name  of  the  segment  for  the  object.  Otherwise,  the  object  is 
located  in  segment  “aidau”  for  initialized  objects  or  "audau”  for  uninitialized  objects. 

Use:  The  RISCAE  run  time  model  specifies  that  sutic  objects  and  constants  be  addressed  using  base  offset  . 

addressing  mode  with  the  global  base  register  (GBR)  and  that  there  is  a  limit  of  64K  bytes  of  toul 
size  of  such  dau.  Pragma  APART  can  be  used  to  specify  objects  which  are  not  to  be  addressed  using 
the  global  base  register  (GBR).  Pragma  APART  may  be  used  if  specific  dau  items  need  to  be  located 


further  APART  than  64K  bytes  or  in  a  large  program  for  which  the  total  size  of  static  objects  and 
constants  is  larger  than  64K  bytes.  Refer  to  the  RISCAE  Progranuner  s  Reference  Manual  for  more 
information  about  location  and  addressing  of  static  objects. 

F.1J.3:  Pragma  INDIRECT 

Form:  pragma  INDIRECT  {subpmgram_name) 

where  subprogram _nam€  is  the  name  of  a  subprogram  which  is  declared  in  the  same  declarative 
region.  A  body  is  not  allowed  for  a  subprogram  to  which  pragma  INDIRECT  applies. 

Allowed  Places:  Pragma  INDIRECT  must  appear  within  the  same  declarative  part  as  the  subprogram  to 
which  it  applies,  following  the  subprogram,  and  prior  to  the  first  use  of  the  subprogram. 

Effect:  A  call  to  a  subprogram  to  which  pragma  INDIRECT  applies  will  cause  the  compiler  to  generate  a 
call  to  the  address  provided  by  the  first  parameter  of  the  subprogram  with  parameters  2  through  N 
of  the  subprogram  being  treated  as  parameters  1  through  N- 1 .  This  provides  the  ability  to  save  the 
address  of  a  subprogram  in  a  variable  or  dau  smicture  so  that  it  may  be  called  later. 

Use.  This  is  used  in  run  time  system  code.  It  should  not  normally  be  used  in  application  programs. 

F.  1.2.4:  Pragma  CONTIGUOUS 

Form:  pragma  CONTIGUOUS  {record jypejxame) 

Allowed  Places:  Pragma  CONTIGUOUS  must  appear  within  the  same  declarative  part  as  the  type  to  which 
it  applies,  following  the  type  declaration  but  prior  to  any  forcing  occurrence  of  the  type. 

Effect:  Pragma  CONTIGUOUS  alters  the  layout  of  an  Ada  discriminant  record  type.  Normally  an  array 
whose  bound  depends  on  a  discriminant  is  mapped  on  to  a  pointer  to  a  dynamically  allocated  string. 
This  pragma  forces  the  compiler  to  lay  out  the  record  and  array  in  a  single  object. 

Use:  This  is  used  in  run  time  system  code  and  should  only  be  used  as  it  is  used  in  the  run  time.  It  should 

not  normally  be  used  in  application  programs. 

F.2:  Standard  Types  and  Implementation-Dependant  Attributes 

There  are  no  implementation-dependent  attributes  provided  by  the  RISCAE  Ada  compiler.  The  fol¬ 
lowing  sections  deflne  the  standard  types  supported  by  the  RISCAE  Ada  compiler  and  the  implementation- 
dependent  values  of  their  attributes. 

F.2.1:  Standard  Types 

The  following  standard  types  are  defined  for  the  RISC  AE  RH32-targeted  compiler, 
type  bytejnteger  is  range  -128  ..  127; 
type  shOTtJntcger  is  range  -32768 ..  32767; 
type  integer  is  range  -2 147483648  ..  2 147483647; 
type  long_integer  is  range  -2147483648  ..  2147483647; 
type  float  is  digits  6  range  -3.40282E+38  ..  3.40282E+38; 
type  long_float  is  digits  15  range  -1.79769E+308  ..  1.79769E+308; 
type  duration  is  delta  2**-14  range  -86400.0 ..  86400.0; 

F.2.2:  Implementation-Dependent  Attributes 

This  section  describes  the  implementation-dependent  values  of  the  attributes  of  the  standard  types. 

Type  INTEGER 

INTEGER’SIZE 


=  32  -  -  bits 


INTEGER’ FIRST 

=  -<2**31) 

- 2.147.483.648 

INTEGER'LAST 

=  (2**31  -  1) 

--  2.147.483.648 

TVpc  LONG.INTEGER 

INTEGER'SIZE 

=  32  -  bits 

INTEGER'HRST 

=  -<2**31) 

- 2.147.483.648 

INTEGER’LAST 

=  (2**3l-  1) 

--  2.147.483.648 

Type  SHORTJNTEGER. 

SHORTJNTEGER’SIZE 

=  16 -bits 

SHORTJNTEGER’HRST 

=  -(2**15) 

- 32.768 

SHORTJNTEGER’LAST 

=  (2**  15-  1) 

--  32.767 

Type  BYTE JNTEGER. 

BYTEJNTEGER’SIZE 

=  8  -  bits 

BYTEJNTEGER’RRST 

=  -<2**7) 

- 128 

BYTEJNTEGER’LAST 

=  (2**7-  1) 

--  127 

Type  FLOAT. 

FLOATSIZE 

FLOATDIGnrS 

FLOATMANTISSA 

FLOATEMAX 

FLOATEPSILON 

FLOATSMALL 

FLOATLARGE 

FLOATMACHINE.ROUNDS 

FLOATMACHINE.OVERFLOWS 

FLOATMACHINE.RADIX 

FLOATMACHINE.MANTISSA 

FLOATMACHINE.EMAX 

FLOArMACHINE_EMIN 

FLOATSAFE.EMAX 

FLOATSAFE.SMALL 

FLOArSAFE_LARGE 


=  32  -  -  bits. 

=  6 
=  21 
=  84 

=  2.0**(-20) 

=  2.0**(-85) 

=  (1.0-2.0**(-21))*2.0**84 
stnie 
=  troe 
=  2 
=  24 
=  128 
=  -125 
=  125 

=  2.0**(-l26) 

=  (1.0-2.0**-21)*2.0**125 


Type  LONG.FLOAT. 

LONG.FLOAT SIZE  =  64  -  -  bits. 

LONG.FLOATDIGITS  =  15 

LONG.FLOATMANTISSA  =  5 1 

LONG_FLOArEMAX  =  204 

LONG.FLOATEPSILON  =  2.0**(-50) 

LONG^FLOATSMALL  *  2.0**(-205) 

LONG^FLOATLARGE  =(1.0-  2.0**-5 1)*2.0**204 

LONG_FLOArMACHINE_ROUNDS  =inje 

LONG.FLOATMACHINE.OVERFLOWS  =  troc 
LONG.FLOATMACHINE.RADIX  » 2 

LONG_FLOAr  MACHINE.MANTISSA  =  53 
LONG_FLOArMACHINE_EMAX  =  1024 

LONG.FLOATMACHINE.EMIN  =-1021 

LONG_FLOArSAFE„EMAX  =1021 

LONG_FLOArSAFE_SMALL  =  2.0**(-1022) 


LONG.FLO  AT  S  AFE_L  ARGE 


Type  DURATION. 

DURATION’DELTA 
DURATION’nRST 
DURATION’LAST 
DURATON’SMALL 

TVpe  PRIORITY. 

PRIORTTYRRST 
PRIORITVLAST 

F.3:  Package  SYSTEM 

package  SYSTEM  is 

type  ADDRESS  is  new  integer. 

NULL, ADDRESS  .  consunt  ADDRESS  .=  0; 

type  NAME  is  (hnw_rh32,  trw_rh32); 

SYSTEM_NAME  ;  consunt  NAME  :=  trw_rh32; 

STORAGE_UNIT :  constant  .=  8: 

MEMORY.SIZE;  constant :«  2**3 1 ;  -  -  In  storage  units 

-  -  System-Dependent  Named  Numbers: 

MIN.INT  .  constant  :=  -2147483648; 

MAXJNT ;  constant  :=  2147483647; 

MAX_DIGITS  ;  constant  :=  15  ; 

MAX.MANTISSA  :  consunt  :=  31; 

FINE.DELTA  ;  constant  :=  2.0**(-31); 

TICK  :  constant  :=  2.0**(-14); 

-  -  Other  System-Dependent  Declarations 

-  -  Legal  values  for  pragma  PRIORITY. 

-  -  There  are  3 1  user  priority  levels. 

-  -  The  default  priority,  if  not  assigned  by  pragma,  is  0. 
subtype  PRIORITY  is  INTEGER  range  1  ..31; 

-  -  NOTE;  The  RISCAE  kernel  supports  higher  priorities 

-  -  under  which  hardware  interrupts  are  disabled. 

end  SYSTEM ; 


F.4:  Restrictions  on  Representation  Clauses 


=  (1.0-:  .0**-51)*2.0**l021 


=  2.0**(-14)-- seconds 
=  -  86_400.0 
=  86_400.0 
=  2.()**(-14) 


=  1 
=  31 


This  section  describes  the  list  of  all  restrictions  on  represenution  clauses. 


“NOTE:  An  implementation  may  limit  its  acceptance  of  representation  clauses  to  those  that  can  be 
handled  simply  by  the  underlying  hardware....  If  a  program  contains  a  representation  clause  that  is  not  ac¬ 
cepted  I  by  the  compiler],  then  the  program  is  illegal.”  (LRM  13. 1  { 10)). 

F.4.1:  Length  Clauses 

Size  specification:  TSIZE. 

The  size  specification  may  be  applied  to  a  type  T  or  first-named  subtype  T  which  is  an  access  type, 
a  scalar  type,  an  array  type  or  a  record  type. 

AI-00S36/07  has  altered  the  meaning  of  a  size  specification.  In  particular,  the  statement  from  the 
LRM  1 3.2.a  that  the  expression  in  the  length  clause  specifies  an  upper  bound  for  the  number  of  bits 
to  be  allocated  to  objects  of  the  type  is  incorrect.  Instead,  the  expression  specifies  the  exact  size  for 
the  type.  Objects  of  the  type  may  be  larger  than  the  specified  size  for  padding.  Note  that  the  specified 
size  is  not  used  when  the  type  is  used  as  a  component  of  a  record  type  and  a  component  clause  specify¬ 
ing  a  different  size  is  given. 

If  the  length  clause  can  not  be  satisfied  by  the  type,  an  error  message  will  be  generated.  In  addition, 
the  following  restrictions  apply: 

access  type:  the  only  size  supported  is  32. 

integer,  fixed  point,  or  enumeration  type:  minimum  size  supported  is  1.  the  maximum  size 

that  is  supported  is  32.  the  size  of  the  largest  prede¬ 
fined  integer  type.  Biased  representation  is  not 
supported. 

floating  point  type:  the  sizes  supported  are  32  and  64.  Note  that  the 

size  must  satisfy  the  DIGITS  requirement.  No 
support  is  provided  for  shortened  mantissa  and/or 
exponent  lengths. 

Specification  of  collection  size:  TSTORAGE_SIZE. 

The  effect  of  the  specification  of  collection  size  is  that  a  contiguous  area  of  the  required  size  will  be 
allocated  for  the  collection.  If  an  attempt  to  allocate  an  object  within  the  collection  requires  more 
space  than  currently  exists  in  the  collection.  STORAGE.ERROR  will  be  raised.  Note  that  this  space 
includes  the  header  information. 

Specification  of  storage  for  a  task  activation:  TSTORAGE.SIZE. 

The  value  specified  by  the  length  clause  will  be  the  total  size  of  the  stacks  (primary  and  secondary) 
allocated  for  the  task. 

Specification  of  small  for  a  fixed  point  type  :  T’SMALL. 

The  value  of  TSMALL  is  subject  only  to  the  restrictions  defined  in  the  LRM(13.2). 

F.4.2:  Enumeration  Representation  Clauses 

Enumeration  representation  clauses  are  supported  with  the  restriction  that  the  values  of  the  internal 
codes  must  be  in  the  range  of  MIN_1NT ..  MAX_INT. 

F.43:  Record  Representation  Clauses 

Record  representation  clauses  are  supported  with  the  following  restrictions: 

•  Allowed  values  in  the  alignment  clause  are  1  (byte-aligned).  2  (half-word 
aligned),  4  (full-word  aligned)  and  8  (double-word  aligned). 


•  In  the  component  clause,  the  storage  unit  oh'set  (the  5ra/(c_simpie_expression 
part)  must  be  a  word  offset  (i.e.  0  or  a  positive  multiple  of  4).  The  range  of  bits 
specified  has  the  following  restrictions:  if  the  starting  bit  is  0.  there  is  no  limit 
on  the  value  for  the  ending  bit;  if  the  starting  bit  is  greater  than  0.  then  the  end¬ 
ing  bit  must  be  less  than  or  equal  to  3 1. 

The  actual  size  of  the  record  object  (including  its  use  as  a  component  of  a  record  or  array  type)  will 
always  be  a  multiple  of  words  (32  bits)  with  padding  added  to  the  end  of  the  record,  if  necessary.  User-speci¬ 
fied  ranges  must  contain  at  least  the  minimal  number  of  bits  required  to  represent  a  (bit-packed)  object  of 
the  corresponding  type;  e.g.  to  represent  an  integer  type  with  a  range  of  0..  IS.  at  least  4  bits  must  be  specified 
in  the  record  representation  specification  range.  For  more  information  about  record  layout,  refer  to  the  RIS- 
CAE  Software  Programmer's  Reference  Manual. 

F.4.4:  Address  Clauses 

An  address  clause  may  be  supplied  for  an  object  (whether  constant  or  variable),  a  subprogram,  or 
a  task  entry,  but  not  for  a  package  or  task  unit.  If  an  address  clause  is  supplied  for  a  subprogram,  a  body  is 
not  allowed  for  that  subprogram. 

An  interrupt  entry  (address  clause  for  an  entry)  may  not  have  parameters. 

F.5:  Implementation  Dependent  Components 

There  are  no  implementation-generated  names  denoting  implementation-dependent  (record)  com¬ 
ponents. 

F.6:  Interpretation  of  Expression  in  Address  Clauses 

This  section  describes  the  interpretation  of  expressions  that  appear  in  address  clauses,  including 
those  for  interrupts.  System. Address  is  declared  to  be  new  INTEGER,  hence,  takes  values  from  -2**3 1  to 
2*’*3 1-1.  For  address  clauses  on  objects  or  subprograms,  these  values  will  be  interpreted  as  (virtual)  ad¬ 
dresses  in  target  memory  as  follows; 

address  >=  0  implies  (virtual)  address  =  adcfress 
address  <  0  implies  (virtual)  address  =«  (2**32)  +  address 

For  an  object; 

The  meaning  of  the  value  given  by  an  address  clause  for  an  object  is  the  (virtual)  address  in  the  target 
memory  assigned  to  that  object. 

For  a  subprogram: 

lire  meaning  of  the  value  given  by  an  address  clause  for  a  subprogram  is  the  (virtual)  address  in  target 
memory  to  which  the  program  will  branch  when  the  user  program  makes  a  call  to  the  subprogram. 
The  user  must  supply  the  code  to  be  executed  and  ensure  that  it  is  located  at  the  indicated  address. 

For  an  entry; 

The  TRW  RH32  SCU  provides  12  interrupt  levels,  0  to  1 1  with  level  0  the  highest  priority,  of  which 
8  are  external  interrupts,  3  are  timer  interrupts,  and  I  is  reserved  by  the  hardware.  If  the  value  given 
by  an  addr^s  clause  fora  task  entry  is  in  the  range  0 ..  1 1,  the  entry  will  be  called  when  the  interrupt 
corresponding  to  that  interrupt  level  is  signaled.  Two  of  the  3  timer  interrupts,  interrupt  levels  2  and 
4,  are  reserved  for  use  by  the  RISCAE  kernel  in  the  implementation  of  package  CALENDAR  and 
to  support  Ada  delay  statements.  If  an  interrupt  entry  attempts  to  use  either  of  these  interrupt  levels, 
PROGRAM.ERROR  will  be  raised  during  activation  of  the  task  containing  the  interrupt  entry. 

The  RISCAE  kernel  also  provides  an  INTERFACE  which  allows  an  application  to  cause  a  software 
interrupt  to  occur.  Values  in  the  range  12  ..  19  are  provided  for  software  interrujjts. 


Any  value  outside  the  range  of  0 ..  19  will  cause  PROGRAM.ERROR  to  be  raised  during  acti  vauon 

of  the  task  containing  the  interrupt  entry. 

F.7:  UNCHECKED  CONVERSION 

There  are  no  restrictions  on  the  use  of  UNCHECKED_CONVERSlON.  Conversions  between  ob¬ 
jects  whose  sizes  do  not  confirm  may  result  in  storage  areas  with  undefined  values. 

F.8:  Input-Output 

This  section  describes  implemenution-dependent  characteristics  of  the  language  predefined  input- 
output  packages. 

•  The  RISCAE  Ada  run  time  provides  no  support  for  external  files  nor  for  STAN- 
DARDJNPUT.  The  predefined  exception  USE_ERROR  will  be  raised  if  an 
attempt  is  made  to  create  or  v.<.:n  any  external  file.  The  predefined  exception 
END_ERROR  will  be  raised  if  an  attempt  is  made  to  read  STAND  ARD_INPUT. 

Suppon  for  STANDARD_OUTPUT  is  implemented  assuming  the  presence  of  a 
console  I/O  device  which  accepts  output  characters.  The  RISCAE  simulator  pro¬ 
vides  the  effect  of  a  console  I/O  device  which  is  used  to  implemert  STAN- 
DARD.OUTPUT.  (Implementation  of  STAND ARD.OUTPUT  for  the  RH32 
ADMisTBD). 

•  Line  terminator  is  ASCII.LF  (line  feed);  page  terminator  is  ASCII.FF  (form 
feed). 

•  The  packages  SEQUENTIAL_IO  and  DIRECT_10  cannot  be  instantiated  with 
unconstrained  composite  types  or  record  types  with  discriminants  without  de¬ 
faults. 

•  Package  LOW_LEVEL_IO  is  not  provided. 

F.9:  Tasking 

This  section  describes  other  implementation-dependent  characteristics  of  the  tasking  run-time  pack¬ 
ages. 

F.9.1:  Scheduling  of  Ada  tasks 

The  scheduler  of  the  Ada  run-time  tasking  system  runs  usks  of  equal  priority  in  the  order  that  they 
became  eligible  to  run  and  allows  them  to  run  until  blocked  or  until  interrupted  by  the  eligibility  of  a  task 
of  higher  priority.  A  task  whose  priority  is  higher  than  the  task  currently  running  may  be  made  eligible  to 
run  by  an  interrupt  or  by  the  expiration  of  a  delay  statement  Such  an  event  will  cause  the  currently  running 
task  to  be  immediately  blocked  so  that  the  higher  priority  task  may  run. 

F.9.2:  Implementation-Dependent  Termination  of  Library  Unit  Tasks 

Even  though  a  main  program  completes  and  terminates  (its  dependent  tasks,  if  any.  having  termi¬ 
nated).  the  elaboration  of  the  program  as  a  whole  continues  until  each  task  dependent  upon  a  library  unit  pack¬ 
age  has  either  terminated  or  reached  an  open  terminate  alternative.  See  LRM  9.4(  1 3). 

F.9.3:  Implementation  of  Calendar 

Support  for  implementation  of  Ada  delay  statements  and  for  the  function  CLOCK  in  package  CAL¬ 
ENDAR  are  provided  by  the  RISCAE  kernel.  The  kernel  implementation  uses  RTC  (Real  Time  Clock)  and 
interrupt  levels  2  and  4  in  the  SCU  of  the  TRW  RH32  processor . 


F.IO:  Other  Matters 

This  section  describes  other  implementation-dependent  characterisacs  of  the  system. 

Restrictions  on  main  program; 

Any  parameterless  procedure  which  is  a  library  unit  may  be  a  main  program  (LRM  10. 1.8). 

Order  of  compilation  of  generic  bodies  and  subunits  (LRM  10.3:9): 

Body  and  subunits  of  generic  must  be  in  the  same  compilation  as  the  specificauon  if  insuntiations 
precede  them  (see  AI-00257/02). 


